…elastic#134169)

This introduces ComponentMetadataRulesPlugin that contains declarative logic for dealing with transitive dependencies on a per dependency level.
Ulitmately we want more finegrained control over our dependencies without loosing information about transitive dependencies.

The initial list of the applied component metadata rules will be more finegrained over time. Initially this is mostly a reflection of how we brought in dependencies before by basically making the transitive dependencies we identified as required where added as direct dependency.

I started looking through the existing dependencies applyging the following pattern:

if no problematic transitive dependency detected, do not apply any component meta data rule.
if only non group dependencies have been problematic, use ExcludeOtherGroupsTransitiveRule which allows transitive dependencies brought with the same groupId as the parent but excludes all others.
Otherwise exclude all transitive dependencies by applying ExcludeAllTransitivesRule
We will add more specific rules in the future as we see the need to "fix' component metadata of thirdparty dependencies.

This change replaces our plain transitive = false approach for non elasticsearch dependencies

Historically we have solved dealing with transitive dependencies and component metadata in this regard by just ignoring it and bringing in dependencies explicitly. This results in

weaker control what we bring in and why
loose information why a dependency is needed and how its tight ot another dependency on the classpath
transitive behavior differed in different context as we only have applied transitivity
Furthermore the way we have configured transitive = false for each dependency resulted in other problems when using other newer Gradle APIs like test suites.

(cherry picked from commit a0e6ea1)

# Conflicts:
#	test/fixtures/url-fixture/build.gradle